REMARKS 

The application includes claims 1-38 prior to entering this amendment. 

The applicants amend claims 1-5, 8-12, 15, 17-18, 20-25, 28-34, and 37-38. 

The application remains with claims 1-38 after entering this amendment. 

The applicants do not add new matter and request reconsideration. 

An Information Disclosure Statement (IDS) is included herewith for submitting 
references cited in prosecution of the corresponding U.S. parent application, U.S. Ser. No. 
10/723,1 18, and in the International Search Report for the PCT application corresponding to this 
parent, PCT/US04/3943 1 . Also included, from the Request For Comments (RFC) series 
published by the Editor of the Internet Engmeering Task Force (IETF), is RFC 3550, which 
goierally describes the RTP and RTCP protocols (and which was incorporated, by reference, in 
applicant's original disclosure on page 10, line 17). This art is submitted pursuant to the 
requirements of 37 C.F.R. §§ 1.56, 1.97, and 1.98. 

In Adhikari, test packets are transmitted between network endpoints (Fig. 3) as RTP 
packets in order to collect QoS measurements (par. 0056). QoS-related data about the packets is 
incorporated, at the endpoints, into the packets themselves (par. 0090). Also recorded in the test 
packet itself is the number and addresses of the routers passed during travel between the 
endpoihts as well as the true path length based on the Time To Live (TTL) field (pars. 0097 and 
0102-0104). RTCP is used by the endpoint to make the QoS report (par. 0108). In Partain, in 
like manner, a "probe" packet is sent between end nodes (denoted "Ingress" and "Egress" in Fig. 
2; col. 3, lines 37-40) that records, within itself, "aggregated" path information as it travels 
between the endpoints. In particular, the probe packet is "marked" at each intermediate router 
where congestion is detected (col. 5, lines 25-33). The DiffServ codepoint of the probe packets 
may be varied to measure congestion levels for different packet classes (col. 5, line 66 to col. 6, 
line 6), and the path-related congestion information can be compiled in a report packet by one of 
the endpoints (col. 5, lines 51-55). It will be noted that neither Adhikari nor Partain describe the 
claimed approach of setting TTL values in the probe packets in such a maimer as to intentionally 
cause faults or discards at the intermediate nodes. 
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Aggarwal describes a method in which a conventional UDP traceroute program (col. 1, 
line 62 to col. 2, line 13) is combined with Simple Network Management Protocol (SNMP) 
queries (col. 3, lines 43-48) to discover the particular routers along a network path. In particular, 
Aggarwal describes how an ICMP response from an intermediate node will be different than the 
ICMP response from a destination node (e.g., for the intermediate node, a "TTL_EXCEEDED" 
response is given, see col. 3, line 66; for the destination node, a "PORT_UNREACHABLE" 
response, see col. 4, lines 22-25). The User Datagram Protocol (UDP) packets employed in 
Aggarwal do not provide any packet ordering or sequencing services and thus do not suitably 
constitute "media" trace packets of the type claimed. Also, further distinctions noted in the 
Remarks section below in connection with the primary reference cited, Selvaggi et al., apply 
with equal force to Aggarwal. 

Drawing Objections 

The examiner objected to the drawings. A replacement sheet for Fig. 2 is attached hereto 
in which, in respect to items 222 and 224, the text "TTL=X=X+1" and "TTL=X=X+2," 
respectively, have been replaced by the text "TTL=X+1" and "TTL=X+2," respectively. A 
replacement sheet for Fig. 4 is also attached in which a reference number, 206, has been added to 
indicate the "TIME TO LIVE" field in the IP header, in accordance with applicant's original 
disclosure (e.g., page 10, line 14). 

Claim Objections 

The examiner objected to claims 9, 29, and 30-38 for informalities. These claims have 
been amended to correct the informalities in the manner indicated by the examiner. 

Claim Rejections Under 35 U.S.C. § 112 

The examiner rejected claims 4-7, 20, 24-27, and 33-36 under 35 U.S.C. § 1 12, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. These claims have been amended to overcome 

the indefiniteness rejection. In particular, in claims 4, 24, and 33 (which serve as base claims for 
claims 5-7, 25-27, and 34-36, respectively), the indefinite language "causing the destination 
endpoint" has been deleted. In claim 20, the reference to RTF packets "with the modified TTL 
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values" has been replaced by a reference to RTP packets "containing TTL values," with the 
substituted language finding direct support in parent claim 17. This resolves the indefiniteness 
rejection in respect to each of these claims. 

Claim Rejections Under 35 U.S.C. § 102 

The examiner rejected claims 1-7, 9-27, 29-36, and 38 under 35 U.S.C. § 102(e) as being 
anticipated by Selvaggi, et al, (U.S. Patent Application Publication No. 2004/0193709). 

Claims 1-7 and 9 

Independent claim 1 is generally directed to a method of analyzing a media path by 
varying a Time-To-Live (TTL) value in media trace packets so as to intentionally cause faults at 
intermediate nodes in the media path and analyzing the fault notices thereupon received from 
these intermediate nodes. Claim 1 is herein amended to add the step of "providing media trace 
packets having a data header field assigned the same priority value as actual media payload 
packets to be sent along the media path." Support for this step is provided in applicant's original 
disclosure, which explains that the media trace packets are like "normal voice RTP packets" 
including "with the same Differentiated Services Code Point (DSCP) bits" (page 5, lines 1 1-12), 
and also in applicant's Fig. 4, which shows the related "T>^e Of Service" (TOS) field in the IP 
header 239. Those of ordinary skill will recognize that in respect to the IPv4 protocol, for 
example, the DSCP bits represent 6-bits of the 8-bit Differentiated Services (DiffServ) field, of 
which the first three bits mark the packet as being within one of four priority classes, which 
convention is backwardly compatible with the first three "precedence" bits (bits 0-2) of the 
(former) TOS field. In other words, claim 1 now specifies that the media trace packets are 
originally provided with the same priority marking as the actual media payload packets that will 
be using the media path. 

Selvaggi et al., as cited in the Action, does describe "media trace packets" (e.g., of RTP 
format) that have TTL fields varied to cause "error messages" at intermediate (connecting) nodes 
along a media (VoIP) path (par. 0051); however, Selvaggi stresses the importance of simulating 
VoIP traffic (par. 0052) and, in particular, simulating such traffic using the payload of the RTP 
(media trace) packet because "routers may treat packets differently depending on their payload" 
(par. 0054; see also par. 0059 discussing "including VoIP data in the RTP payload"). In 
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distinction to Selvaggi's approach, amended claim 1 highlights the importance of matching, in 
the "header" field of the original media trace packet (not its "payload" field) the "priority value" 
of the actual media payload packets (versus merely duplicating VoIP content). The approach of 
amended claim 1 ensures that the media trace packets and actual media payload packets start 
along the media path with the same priority value so that the QoS-related network conditions 
experienced by the trace packets will more closely reflect those encountered by the actual media 
payload packets. 

Based on the foregoing remarks, amended claim 1 has now been shown to patentably 
define over Selvaggi et al. Claims 2-7 and 9, each depending irom claim 1 , contain every 
limitation of claim 1 and likewise define patentably over the art. However, even independently of 
base claim 1 , at least claims 2-3 and 5, as amended, patentably define over the art, as will now be 
described. 

Amended claim 2 requires formatting the media trace packets as Real Time Protocol 
(RTP) payload packets that travel "starting with the same priority value" along the same media 
path as RTP payload packets containing media content with "the same priority value being 
assigned by an Internet Protocol (IP) header field." In other words, amended claim 2 clarifies 
that the media trace packets not only start along the "same media path" but also "with the same 
priority value" as the media content packets (possibly subject to later change by an intermediate 
network device) and that this priority value, though associated with trace packets formatted as 
RTP packets, is actually assigned in the Internet Protocol (IP) header field (see the "Type of 
Service" field included in the IP header 239 in applicant's Fig. 4 in conjunction with the above 
discussion of claim 1). Selvaggi et al., as cited in the Action, may describe RTP trace packets, 
but says nothing about the importance, when collecting QoS-related information about media 
paths using media trace packets, of matching packet priorities as well as physical paths. Nor does 
Selvaggi say anything about the significance of matching fields not only in the media-carrying 
layer (e.g., RTP) but also in other protocol layers (e.g., in the IP protocol layer). Accordingly, 
even independently of claim 1, amended claim 2 patentably defines over the cited art. 

Amended claim 3 requires conducting a media signaling protocol establishing the media 
path between a source and destination endpoint, using a same media header format for the trace 
and media payload packets, and setting the TTL values in the trace packets low enough to cause 
a fault condition in one of the intermediate nodes "such that a portion of each media trace packet 
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causing the fault condition is returned in a corresponding reject notice to the source endpoint." 
As indicated in applicant's original disclosure (e.g., on page 6, line 21) this approach enables, for 
example, the source endpoint to better correlate each reject notice with the particular media trace 
packet responsible for causing the notice (see original disclosure, page 6, Unes 22-23). Thus, 
referring to applicant's Fig. 4, the reject notice may incorporate the RTP header fields of the 
responsible trace packet, which is useful for identifying the trace packet's original source (e.g., 
the S5^chronization source/SSRC and contributing source/CSRC identifiers) as well as for 
providing valuable QoS information (e.g., sequence number and timestamp). 

Though Selvaggi is somewhat vague concerning what information is specifically 
contained in its "error messages" (see par. 0051), Selvaggi's error messages provide a "TTL 
expired in transit" alert corresponding to that of an Internet Control Management Protocol or 
ICMP packet (of type 11, code 0). In other words, the error message that Selvaggi returns when 
the TTL value of its RTP trace packet reaches zero at an intermediate node appears to be a 
conventional ICMP notice. However, desirable information may be lost using such ICMP return 
notices. For example, the IP source and destination addresses contained in the IP header portion 
of the ICMP notice may be modified from those of the original RTP trace packet if this trace 
packet is mixed with other RTP packets during its travel along the media path (under the claimed 
approach, the SSRC and CSRC identifiers that may be included from the original media trace 
packet overcome this difficulty). Furthermore, while QoS information may be extracted fi-om the 
ICMP notice (using, for example, the ID and Sequence fields obtainable with the P protocol to 
correlate return ICMP notices with particular outgoing trace packets), such QoS information only 
relates to round-trip characteristics (along the entire path between the source and intermediate 
node and back again) and not to one-way travel characteristics (as may be preserved under the 
claimed approach by recording in the reject notice, when the responsible media trace packet 
arrives at the intermediate node, the timestamp and sequence number of this trace packet as well 
as the corresponding SSRC or CSRC address.) For such reasons, then, amended claim 3 
patentably defines over the art of record even independently of its base claim, claim 1 . 

Amended claim 5 is directed to a method in which a member bit in the media trace packet 
causes the destination endpoint to "immediately" generate a media path analysis report for the 
media trace packets. As related claim 6 makes clear, this report may constitute a Real Time 
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Control Protocol (RTCP) report. Support for amended claim 5 is provided in applicant's original 
disclosure, for example, on page 14, lines 23-25. 

It may be noted that the time from when the report is generated to when it is sent may, if 
desired, be varied depending, for example, on bandwidth controls conventionally designed to 
mitigate network congestion when RTCP is used (see applicant's disclosure, page 19, lines 20- 
23). It may also be noted that tha-e is a difference between the fault notice sent back by an 
intermediate node (e.g., which in one preferred embodiment is an ICMP-formatted message 
including part of the trace packet in its payload as used by the source for conducting the QoS 
analysis; see appKcant's disclosure, page 4, line 7; page 5, hne 27 to page 6, line 3; and page 6, 
lines 21-23) and the analysis report sent back by the destination endpoint or node (e.g., which in 
one preferred embodiment is an RTCP -formatted message with the QoS analysis conducted at 
the destination before the message is returned to the source; see applicant's disclosure, page 14, 
lines 23-25 and page 17, lines 5-8). 

In Selvaggi et al., there is no explicit mention of an "analysis" (or RTCP) report being 
generated at the destination node upon trace packet receipt. Indeed, Selvaggi appears to suggest 
that the destination node returns an "error message" (or ICMP notice) like those generated by the 
intermediate nodes (see fburth-to-last sentence in par. 0051 ; such a notice might indicate an 
unreachable destination using a Type 3 ICMP alert, as described in the Aggarwal et al.reference 
that was earlier mentioned at the beginning of these Remarks). Even presuming that Selvaggi 
provides, for example, RTCP reports at the path destination in response to RTP trace packets, 
there is nothing in this reference to suggest that such RTCP reports are, as claimed, generated 
"immediately" based on triggering by "a member bit" in the trace packets (e.g., which identifies 
a series of trace packets as being members of the same TTL group). At best, Selvaggi would 
periodically generate and send RTCP reports in accordance with a conventional "report interval" 
designed to be increased as the number of intended recipients increases (see RFC 3550, first 
paragraph on pages 26 and 27; note that RTCP "feedback" reports, even when based on RTP 
packets from one source, are typically broadcast to many participants to allow each participant to 
discriminate between local and global path problems; see RFC 3550, page 20, first paragraph). In 
other words, conventional generating and sending of RTCP return packets does not provide for 
separate grouping, analysis, and QoS reporting on only those media trace packets involved in the 
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"last" jump to the destination node (as demarcated by the claimed "member bit"). Hence, even 
apart from base claim 1, amended claim 5 patentably defines over the cited art. 

Claims 10-16 

As a preliminary matter, it will be noted that base claim 10 has been amended and that 
corresponding minor amendments have been made, in particular to dependent claims 1 1 and 12, 
solely to preserve proper antecedent basis. Apart from this comment, these particular dependent 
claims are not fiirther discussed separately in these Remarks. 

hidependent claim 10, as amended, is directed to a network processing device capable of 
establishing an IP network media session and modifying a Time To Live (TTL) value "in 
respective sets of media frace packets that intentionally cause rejection by "corresponding 
respective" intermediary nodes used in the media session "where transmittal of the respective 
sets of media trace packets is selectively subject to rate-limiting control." In other words, the 
interval between fransmission of respective sets of the media frace packets can be selectively 
increased or decreased. Support for amended claim 10 is found in appUcant's original disclosure 
on page 1 1, line 24, which also indicates that this approach can be used to mitigate DoS (denial 
of service) attacks. That is, if such an attack occurs so as to conventionally cause flooding of the 
network, traffic congestion can be reduced by decreasing (or "rate-limiting") the transmission of 
the media frace packets. While Selvaggi does disclose a processing device (Fig. 4) for use at the 
endpoint nodes that includes a routing module 460 providing simvilated media packets of 
decrementing TTL value in order to serve a fraceroute fimction (see pars. 0049-0051), nowhere 
does Selvaggi mention providing rate-limiting ftinctionaUty in respect to fransmission of these 
path-tracing packets. Thus amended claim 10 patentably defines over the cited art, and so also do 
claims 11-16, which depend from claim 10 and contain every limitation of that base claim. 
However, as will now be described, at least claims 14 and 15 patentably define over the art even 
independently of claim 10. 

Claim 14 calls for the processing device of claim 13, wherein the claim 10 processor 
interjects media frace packets in the same session with the actual media payload packets when a 
"trigger event" is detected, which trigger event is specified as being a Real Time Confrol 
Protocol (RTCP) report. That is, the source processor (as defined by claim 10) is induced to send 
media frace packets when triggered by an RTCP report prepared by the destination processor for 
the session. As noted above in the discussion of claim 5, Selvaggi says nothing about RTCP 
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reports. (Paragraph 0051 of Selvaggi, as cited in the Action, refers to "error messages" being 
returned, from both the intermediate and destination nodes, that provide the type of "TTL 
expired" alert traditionally associated with an ICMP message.) At best, even if one deems RTCP 
reports to be a secondary result attributable to Selvaggi from its use of RTP-formatted packets, 
Selvaggi nowhere describes using such RTCP reports to serve as a trigger, in the context of a 
media session in which actual media payload packets are exchanged, for the source processor to 
interject trace packets in order to test the intermediate nodes. Thus claim 14, even independently 
of claim 10, patentably defines over the art. 

Claim 15 calls for the processing device of claim 10 wherein the TTL values are 
modified "in media trace packets" that are formatted as media payload packets that contain no 
actual media payload "but rather contain an artificial media payload of low volume noise." 
Support for this feature is found in applicant's original disclosure on page 11, lines 20-21. This 
claim is related in coverage to that of claims 8, 28, and 37, which are discussed below in the 
section of these Remarks that cover obviousness rejections. At this juncture, suffice it to say that 
using such a payload facilitates regulation of the size of the media trace packets. Thus the media 
trace packets are readily conformed to the uniform size of regularly sampled actual media 
payload packets (see applicant's disclosure, page 21, lines 22-24) to enable normal receiver 
processing at the destination while avoiding, due to the low volume noise, disturbing playback 
effects (see disclosure, page 11, lines 20-21). Moreover, the average rate of transmission of the 
trace packets from the source is thereby readily confroUed or rate-limited so as to mitigate 
network congestion of the type caused, for example, by denial-of-service (DoS) attacks (see 
disclosure, page 11, lines 22-24). Selvaggi only mentions "simulating VoIP fraffic in a payload" 
of its RTP traceroute packets (par. 0054) in order that intervening routers will treat these packets 
like conventional VoIP packets but fails to further mention that randomly or artificially 
generated "low volume noise" may also be used. For further discussion of this feature in 
connection with art other than Selvaggi, see the discussion below of claims 8, 28, and 37. 

Claims 17-20 

As a preliminary matter, confusing labels in independent claim 17 and its dependent 
claim 1 8 have been revised so that they now read as references to media "trace" packets instead 
of media "payload" packets. This more clearly delineates the trace packets from packets 
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containing actual media payloads and is consistent with the manner in which these terms are 
used in claims that have abeady been discussed. In addition, surplus language in dependent claim 
18 has been deleted. Apart from this, dependent claim 18 is not fiirther discussed separately in 

these Remarks. 

Claim 17, as amended, is directed to an intermediary node in an IP media session 
comprising a processor configured for decrementing the Time to Live (TTL) values of media 
trace packets with TTL values intentionally set to be discarded before receipt by the session 
destination, discarding the trace packets when the decremented TTL values are zero, and sending 
out a rejection notice for any discarded trace packets "where transmittal of respective rejection 
notices is selectively subject to rate-limiting control." Support for amended claim 17 is provided 
in applicant's original disclosure on page 11, lines 23-24 as read in conjvmction with page 5, lines 
26-28. Conventionally, when the processor of an intermediate node decrements the TTL value of 
a trace packet to zero (generally a UDP trace packet, though Selvaggi does describe using RTP 
trace packets in par. 0051), it immediately generates and returns an ICMP 'TTL expired" alert 
(e.g., ICMP message type 11, code 0). Certainly Selvaggi suggests nothing more than this. 
However, amended claim 17 fiirther requires that transmittal of such rejection notices by the 
intermediate node be "selectively subject to rate-limiting control." In other words, under the 
approach of claim 17, the processor of an intermediary node may selectively limit the rate at 
which QoS-related rejection notices are returned in a manner traditionally associated with a 
destination node. It will be noted that a destination node may wait to return a QoS-related RTCP 
report subject to whatever bandwidth-limiting controls are in place (for example, the reporting 
interval between scheduled RTCP reports is conventionally increased with the number of RTCP 
recipients; see the first paragraph of page 27 of RFC 3550). The claimed feature may thus be 
used, for example, to mitigate network congestion during a denial-of-service (DoS) attack (see 
applicant's disclosure, page 11, lines 23-24). The usefiilness of this feature will be fiirther 
recognized upon considering that each intermediate processor in the media path will preferably 
generate multiple reject notices to facilitate QoS analysis of each node or Unk back at the source. 

Based on the reasons just given, amended claim 17 patentably defines over the cited art, 
and so also do claims 18- 20, which depend from claim 17 and share every limitation of that base 
claim. Even apart from claim 17, however, at least claim 20, as amended, independently defines 
patentably over the art. 
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Amended claim 20 calls for the media trace packets received by the intermediary 
processor of claim 17 to be RTP packets containing TTL values that enable passage through a 
firewall between a source endpoint and a destination endpoint for the media session "while also 
immediately causing selectively the destination endpoint to generate a QoS-related notice" (e.g., 
an RTCP report, see applicant's original disclosure, for example, on page 14, lines 23-25). As a 
preliminary note, it will be recognized that the predetermined destination address and port of 
session-based RTP trace packets will normally ensure their passage through a firewall (as 
contrasted, for example, with a UDP traceroute packet specifying ephemeral ports; see 
appHcant's disclosure, page 1, lines 21-22 and page 2, lines 9-10). 

Of more particular note, it will be recognized that the subject matter of amended claim 20 
is, in a sense, the complement of the subject matter of amended claim 1 7. That is, whereas claim 
1 7 describes, in the context of an intermediary processor, a rate-limited report-returning 
functionality more conventionally associated with a destination processor; claim 20 describes, in 
the context of a destination processor, an immediate report-generating functionality more 
conventionally associated with an intermediary processor. That is to say, it is conventional for 
destination processors to generate and send a QoS-related RTCP report according to a rate- 
limited schedule (rather than to selectively generate the RTCP report "immediately," as claimed). 
This is done so that networks are not unduly congested by RTCP control reports, the likelihood 
of which increases as the number of RTCP recipients increases (as noted above, a destination 
node may receive RTP packets firom one source and then broadcast the corresponding RTCP 
"feedback" report about those packets to multiple other sources so that these other sources can 
separately decide if network problems are "local" or "global;" see the first paragraph of pages 10 
and 20 of RFC 3550). As further discussed above in connection with amended claim 5, the 
advantage to "immediately" generating, if not sending, the RTCP report "selectively" (e.g., 
based, in claim 5, on the presence of a special "member bit"), is that the QoS information 
contained in the RTCP report may then be limited to reflect packet conditions as seen only by 
related media trace packets involved in their "last" jvimp to the destination node (rather than as 
seen by all the RTP packets received at the destination during some reporting interval regardless 
of their TTL and relative timing relationship). Accordingly, amended claim 20 patentably 
defines over the cited art even independently of base claim 17. 
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Claims 21-27 and 29: also Claims 30-36 and 38 

As noted in the Action (bottom of page 7), original claims 21-27 and 29 were system 
claims having corresponding limitations to those of method claims 1-7 and 9. This relationship 
has been preserved in the amended claims, so that the remarks above in support of the 
patentability, over the art, of amended claims 1-7 and 9 apply with equal validity and force to 
amended claims 21-27 and 29, respectively. Equivalent correspondence with amended claims 1- 
7 and 9 also holds in respect to the computer readable medium that is described in amended 
claims 30-36 and 38, respectively. 

Claim Rejections Under 35 U.S.C. § 103 

Claims 8. 28. and 37 

The examiner rejected claims 8, 28, and 37 under 35 U.S.C. § 103(a) as being 
unpatentable over Selvaggi in view of Barrack, et al, (U.S. Patent Application Publication No. 
2004/0008715). In particular, while noting that Selvaggi "does not specifically disclose causing 
the media trace packets to play out low volume noise when received by a destination endpoint," 
the Action observes that "comfort noise insertion" is disclosed in Barrack (pars. 0012 and 0088) 
and would be obvious to add to Selvaggi "to avoid annoying the listener." 

In response, applicant has amended claims 8, 28, and 37 so that each of these claims now 
specifies not only causing the trace packets to play out low volume noise when received by the 
destination but also that this low volume noise is caused "by inserting the low volume noise into 
media payload fields of the media trace packets before sending the media trace packets along the 
media path" (refer to applicant's disclosure, page 11, lines 20-21). In other words, Barrack only 
discloses inserting the low volume noise at the destination device itself (e.g., in playback 
scheduling engine 100 in Fig. 1), which occurs after (not "before," as claimed) the media packets 
have been sent along the media path. Such insertion is done, in Barrack, to mitigate the "eerie" 
blackout effect experienced during playback due to "silence suppression" techniques. In 
accordance with such techniques, "transmission" of media packets "of low signal energy" is 
suppressed at the sending end in order to reduce data transmission bandwidth (see Barrack, par. 
001 1). Accordingly, while Barrack might teach inserting low volume noise into media packets at 
the destination, it does not teach inserting such noise into the payload of packets "before" such 
packets are sent down the media path (which presumably would worsen the very problem of 
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network congestion that "silence suppression," as combined with Barrack's teachings, is 
designed to mitigate). What Selvaggi and Barrack fail to suggest, either separately or in 
combination, is that insertion of such low noise payloads in the media trace packets allow a 
conventional receiver at the destination end to process the media trace packets without special 
configuration (such as a component for inserting low noise) as if they were actual media payload 
packets and without any disturbing playback effects (such as sound or other media blackouts). 
Use of such low noise payloads makes it easy to pad the media trace packets to conform to the 
uniform size of regularly sampled actual media payload packets and faciUtates sending trace and 
media packets at uniform rates to foil traffic analysis attacks (see applicant's original disclosure, 
page 21, lines 23-24 and page 23, lines 14-15). Such padding also facilitates deployment of the 
selectively rate-limiting packet processing mechanisms discussed above in connection with 
independent claims 10 and 17. Accordingly, claims 8, 28, and 37 define patentably over the 
cited art, whether taken separately or in combination, as to render untenable any obviousness 
rejection. 

Conclusion 

For the foregoing reasons, the applicants request reconsideration and allowance of claims 
1-38. The applicants encourage the examiner to telephone the undersigned if it appears that an 
interview would be helpfiil in advancing the case. 
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